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PREFACE 


This  report  documents  research  conducted  under  Project  AIR  FORCE  by  The 
Rand  Corporation.  The  work  described  here  was  performed  as  part  of  the  project 
entitled  "Analysis  of  Systems  for  Air  Force  Education  and  Training”  under  Rand's 
Manpower,  Personnel,  and  Training  Program.  It  is  an  appendix  to  the  third  volume 
in  a series  presenting  the  MODIA  planning  system.  MODIA,  a Method  of  Designing 
Instructional  Alternatives,  is  a system  of  people,  computer  programs,  and  proce- 
dures that  allows  the  rapid  specification  and  simulation  of  courses  of  instruction 
during  the  early  stages  of  instructional  design.  It  complements  and  augments  the 
present  Air  Force  Instructional  System  Development  (ISD)  process. 

The  development  of  MODIA  has  been  supported  by  the  Deputy  Chief  of  Staff/ 
Personnel,  Headquarters  United  States  Air  Force,  and  the  Air  Training  Command, 
especially  DCS/Technical  Training,  the  Training  Development  Directorate,  and 
personnel  at  the  Keesler  Technical  School.  It  is  part  of  Rand’s  continuing  research 
effort  in  the  areas  of  planning  and  management  in  education,  education  technology, 
and  the  cost  and  effectiveness  of  education  systems. 

This  appendix  to  Vol.  3 is  intended  for  those  readers  charged  with  maintaining 
and  modifying  the  User  Interface  (UI)  program.  Aside  from  some  additional  design 
considerations  not  described  in  the  text  of  the  report,  it  contains  only  a more 
detailed  description  of  the  operation  of  the  UI. 

The  series  of  MODIA  reports  includes: 


R-1700-AF,  MODIA:  Vol.  1,  Overview  of  a Tool  for  Planning  the  Use  of  Air 
Force  Training  Resources,  Polly  Carpenter-Huffman. 

R-1701-AF,  MODIA:  Vol.  2,  Options  for  Course  Design,  Polly  Carpenter- 
Huffman. 

R-1702-AF,  MODIA:  Vol.  3,  Operation  and  Design  of  the  User  Interface, 
Polly  Carpenter-Huffman,  Misako  Fujisaki,  and  Ray  Pyles. 

R-1703-AF,  MODIA:  Vol.  4,  The  Resource  Utilization  Model,  Margaret  Gal- 
legos. 

R-1704-AF,  MODIA:  Vol.  5,  A User’s  Guide  to  the  Cost  Model,  Ronald  Hess 
and  Phyllis  Kantar. 
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The  following  description  of  the  User  Interface  (UI)  program  of  MODIA  (a 
Method  Of  Designing  Instructional  Alternatives)  is  intended  for  readers  responsi- 
ble for  maintaining,  modifying,  or  transporting  that  program  to  another  computer 
system.  It  is  technical  in  content,  and  we  assume  that  the  reader  is  familiar  with 
program  operation  as  described  in  the  text  of  this  report,, R-1702-AF.  ‘3—  < 

Figures  and  tables  appearing  in  this  appendix  have  been  prefixed  with  an  "A” 
(e.g.,  Table  A.l,  Fig.  A.7).  Numbers  with  no  prefix  refer  to  figures  and  tables  in  the 
text  of  the  report. 

Aside  from  some  additional  design  considerations  not  described  in  the  text,  this 
appendix  contains  only  a more  detailed  description  of  the  operation  of  the  UI. 
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DESIGN  CONSIDERATIONS 

When  the  UI  was  designed,  it  was  unclear  what  computer  the  Air  Training 
Command  might  select  as  the  host  for  MODIA  operations.  One  of  the  major  goals 
of  the  design  process,  therefore,  was  to  maximize  the  system’s  transportability.  To 
this  end,  we  made  the  following  decisions: 

• To  use  ANS  FORTRAN  as  the  language, 

• To  centralize  I/O  operations, 

• To  modularize  individual  program  functions, 

• To  impose  a sequential  (jobstream  or  overlay)  control  structure. 

The  selection  of  ANS  FORTRAN  was  a result  of  two  considerations:  (1)  the 
greater  transportability  of  the  ANS  subset  of  FORTRAN  than  of  COBOL  or  PL/I, 
and  (2)  the  slightly  higher  efficiency  of  FORTRAN  in  its  use  of  core  storage.  Al- 
though FORTRAN  is  found  on  a variety  of  machines,  each  manufacturer  has 
enhanced  the  ANS  version  to  capitalize  on  the  unique  capabilities  of  his  own 
machine.  A program  developer  can  be  assured  his  program  will  operate  on  another 
machine  only  if  the  program  is  confined  to  the  ANS  subset  of  FORTRAN. 

The  selection  of  ANS  FORTRAN  as  the  implementation  language  constrained 
the  design  of  the  UI  program  in  one  very  important  way.  Data  files  were  limited 
to  sequential  formats.  This  limitation  is  significant  because  the  UI  program  must 
converse  interactively  with  a planner  about  a very  complex  problem.  The  con- 
straints of  a "reasonable”  response  time  conflicted  sharply  with  the  time  required 
to  access  several  sequential  files  to  obtain  or  save  information  of  interest  to  the 
course  design.  To  attain  the  desired  response  time,  we  found  it  necessary  to  retain 
a significant  portion  of  the  course  design  data  in  core  memory  during  the  operation 
of  the  UI  program.  This  decision  caused  the  amount  of  core  memory  required  for 
UI  operation  to  be  higher  than  originally  desired,  particularly  where  resource 
constraints  were  described.  This  complex  interactive  program  requires  a fairly 
large  amount  of  core  storage  during  its  operation — approximately  292  thousand 
eight-bit  bytes  of  core  memory  on  the  IBM  370  computer  for  the  largest  module. 
As  a result,  the  UI  operation  is  limited  to  the  medium-to-large  scale  computer 
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installations,  including  a few  large  "mini-computers,”  that  have  enough  core  stor- 
age available. 

Input/Output  (I/O)  operations  on  different  computer  systems  are  frequently 
installation  dependent.  Even  when  the  same  main  frame  computer  is  used,  the 
operating  system  and  the  characteristics  of  magnetic  tapes,  disks,  and  other  record- 
ing media  vary  significantly  from  one  computer  installation  to  another.  Although 
this  problem  is  partly  solved  on  most  general-purpose  computer  systems  by  some 
logical/ physical  file  assignment  functions  provided  by  the  operating  system  for  the 
recording  media,  interactive  terminal  I/O  to  an  on-line  planner  is  still  unstandard- 
ized across  computer  systems.  In  most  cases,  even  the  interface  to  the  routines  that 
cause  output  and  read  input  at  the  terminal  varies  from  site  to  site.  We  therefore 
decided  that  the  functional  programs  would  communicate  with  the  planner  and  the 
recording  media  that  hold  the  intermediate  course  design  information  through 
internal  UI  routines.  These  routines,  described  in  Table  A.l,  would  be  modified 
from  site  to  site  as  the  need  arose.  Modifications  to  the  I/O  operations  between  sites 


Table  A.l 

Input/Output  Routine  Description 


Routine 

Name 

Description 

ITRALT 

Controls  and  performs  input/output  operations  to 
the  planner’s  terminal. 

IWRREC 

Writes  arrays  of  data  to  sequential  files  in  a caller 
specified  format. 

IRDREC 

Reads  arrays  of  data  from  sequential  files  in  a 
caller  specified  format. 

IRDSMT 

Controls  the  generation  of  the  text  of  a question 
at  a remote  terminal  (through  ITRALT)  and 
checks  the  reading  and  legality  of  the  planner’s 
response.  Terminates  UI  program  operation  if 
the  planner  so  requests. 

ITOA 

Converts  an  integer  to  its  alphanumeric  repre- 
sentation, one  character  per  word. 

ATOI 

Converts  an  alphanumeric  string  that  contains  one 
alphanumeric  character  per  word  to  an  integer  and 
indicates  an  error  if  a non-numeric  character  is 
encountered. 

ISPACE 

Spaces  a specified  number  of  lines  at  the  remote 
terminal. 

CONVRT 

Converts  an  alphanumeric  string  to  integer. 

Additional  routines  may  be  required  for  the  UI  on  computers 
other  than  the  IBM  370.  The  following  routines  are  currently 
required  on  the  Honeywell  computer  at  Keesler  AFB: 

IBCDAS 

Converts  input  BCD  character  string  to  ASCII  from 
remote  terminal. 

IAS BCD 

Converts  ASCII  character  string  to  BCD  for  output 
to  remote  teimina). 
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should  be  straightforward,  although  dependent  upon  the  complexity  of  the  change 
required.  For  example,  a complex  change  requiring  internal  character  conversion 
was  carried  out  in  only  a few  days  on  the  Honeywell  6060  at  Keesler  AFB  when 
MODIA  was  installed  there. 

To  conserve  core  storage  during  operation,  the  UI  program  is  broken  into 
several  functional  modules,  so  that  only  the  instructions  and  data  relevant  to  a 
particular  phase  of  the  overall  course  planning  process  occupy  core  storage  at  any 
time.  Without  this  modularity,  the  UI  program  would  require  several  times  the 
amount  of  core  storage  currently  required.  Each  module  communicates  with  the 
others  by  the  sequential  files  already  mentioned.  The  modularity  also  provides  the 
basis  for  the  iteration  of  the  course  design  as  described  in  the  text. 

Finally,  because  not  all  operating  systems  support  complex  job  structures  or 
program  and  data  overlay  operations,  the  control  structure  is  confined  to  the  sim- 
plest conceivable  form.  The  UI  program  performs  a sequential  operation  of  the 
functional  modules  or  planning  phases,  with  the  ability  to  start  at  any  module  in 
the  sequence  and  to  terminate  at  any  point,  permitting  the  planner  to  iterate  the 
design  and  to  abort  a design  session.  Therefore,  there  are  two  different  control 
structures — a job  stream  and  an  overlay.  In  the  job  stream  structure,  shown  in  Fig. 
A.l,  each  module  operates  as  an  independent  program  in  sequence  within  a batch 
job  stream  in  the  computer  system.  The  job  stream  checks  a status  word  controlled 
by  the  UI  program  after  the  completion  of  each  module  to  determine  where  control 
is  to  be  transferred.  Each  module  indicates  by  the  status  word  whether  the  job  is 
to  be  aborted  or  to  continue  to  the  next  sequential  module.  The  job  is  aborted  if  the 
planner  enters  a "Q”  in  response  to  any  UI  question. 

In  addition,  the  first  module  in  the  job  stream  permits  the  planner  to  select  a 
planning  phase.  The  selection  is  indicated  to  the  job  stream  by  the  same  status 
word,  and  this  selection  is  performed  by  the  job  stream.  In  the  overlay  structure, 
a more  innovative  design  can  be  envisioned,  permitting  the  planner  to  cycle  back 
to  an  earlier  phase  without  terminating  the  job,  but  the  only  overlay  structure  used 
so  far  has  simply  mimicked  the  job  stream  structure  described  above. 

The  design  of  the  UI  program  has  been  generally  constrained  by  the  effort  to 
maximize  transportability  to  other  machines.  Although  other  tradeoffs  were  con- 
sidered, we  decided  the  system’s  ultimate  usefulness  would  be  adversely  affected 
if  it  were  limited  to  a single  computer  or  a limited  subset  of  computers. 


PROGRAM  DESCRIPTION 

The  User  Interface  program  consists  of  eight  modules  that  produce  intermedi- 
ate descriptions  of  the  course  design  for  the  planner  and  a ninth  module  that  then 
generates  the  final  course  design  data  for  the  Resource  Utilization  Model  (RUM): 

1.  Select  the  Planning  Phase 

2.  Describe  Objectives  and  Tests 

3.  Describe  Student  Population  and  Course  Diversification 

4.  Describe  Teaching  Policy 

5.  Describe  Test  Details 

6.  Describe  Resources 

7.  Describe  Resource  Constraints 
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Fig.  A.l — MODI  A job  stream  control 
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8.  Describe  Resource  Utilization  Model  Parameters 

9.  Convert  Course  Design  Data  to  RUM  Format 

The  following  description  includes  flow  diagrams  for  each  module.  The  reader 
should  refer  to  the  text  for  examples  of  user  interaction  for  the  modules. 

Before  describing  each  module,  we  shall  discuss  their  interaction  by  the  sequen- 
tial file  media.  Sequential  disk  files  are  used  to  maintain  this  communication,  but 
tape  files  could  be  used  with  some  minor  modification  of  the  system.  The  file  names 
and  the  corresponding  FORTRAN  data  set  reference  numbers  are  shown  in  Table 
A.2,  and  Table  A.3  shows  each  file’s  use  bv  each  module.  The  files  contain  data  about 
intermediate  stages  in  the  course  design  so  that,  by  starting  at  the  proper  module, 
the  planner  can  revise  the  course  design  without  re-entering  all  data  about  the 
course. 

Module  1:  Select  the  Planning  Phase 

The  first  module  allows  the  user  to  select  his  planning  phase.  If  this  is  the 
planner’s  first  session,  the  second  module,  Describe  Objectives  and  Tests,  must  be 
selected;  otherwise,  any  module  may  be  selected  for  continuation  or  iteration  of  a 
course  design.  Fig.  A.2  shows  the  flow  diagram  for  this  module;  Fig.  5 illustrates 
a user  interaction  with  it.  Job  stream  control  recognizes  the  selection  and  activities 
of  the  desired  module. 

Module  2:  Describe  Objectives  and  Tests 

In  this  module,  the  planner  lists  the  objectives  to  be  taught  and  identifies  the 
placement  of  tests  and  the  related  reviews  and  critiques.  The  flow  diagram  in  Fig. 
A.3  shows  the  major  steps  taken  in  this  module,  and  Fig.  6 gives  an  example  of  the 
interaction  of  the  module  with  the  planner. 


Table  A.2 

User  Interface  Files 


FORTRAN 
Data  Set 
Reference 
Number 

File 

Name 

For  Format 
See 

2 

LEFIL.DESC 

Fig.  A.  12 

3 

LEFIL.F24 

Fig.  A.  11 

4 

ILEFIL 

Fig.  A.  11 

8 

POP. FILE 

Fig.  A.6 

9 

OBJ.FILE 

Fig.  A.4 

10 

HMWKLN 

Fig.  A. 8 

11 

SCHD.TIM 

Fig.  A. 18 

12 

RUMINPU 

Table  A.9 

13 

RUMRES 

Fig.  A. 16 

14,2 

LEFIL.D2 

(File  is  referenced  as 

14  in  Module  6;  as  2 
in  Modules  7 and  9) 

Fig.  A.  12 

LlL 


Input 

Output 
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Fig.  A.2 — Select  the  planning  phase  flow  diagram 


First,  the  names  of  the  objectives  are  collected  in  the  order  in  which  they  will 
be  taught.  Next,  each  objective  is  presented  to  the  planner  in  sequence,  allowing 
him  to  assign  one  or  more  subject  matter  types  appropriate  for  teaching  that 
objective.  Each  objective  is  replicated  by  the  UI  program  for  each  subject  matter 
type  assigned  to  it.  This  first  expansion  of  the  training  objectives  is  printed.  Then 
the  program  requests  the  tests,  reviews,  critiques,  recycle  points,  and  failure  poli- 
cies from  the  planner.  If  there  are  tests,  the  planner  establishes  the  points  at  which 
they  are  given  along  with  the  subject  matter  types  for  each  test  and  review.  After 
the  planner  enters  this  information,  the  UI  program  presents  the  second  expansion 
of  the  objectives,  including  the  reviews,  critiques,  and  tests  in  a resequenced  list. 
This  information  is  recorded  in  the  file  OBJ.FILE  in  the  format  shown  in  Fig.  A.4. 
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KEY 

FAILRATE* 

MAX  .NO. 

N.OBJ* 

»» 

RECYCLES* 

A5  A3  13 

Repeated  N.OBJ  times: 


KEY 

OBJECTIVE 

OBJ.NAME* 

S.M. 

TEST 

“2” 

NUMBER 

TYPE 

A4 

A8 

A2 

A1 

KEY 

“3” 

“0” 

14 


FAILRATE  = Percentage  of  failures  in  the  course. 

MAX.NO.RECYCLES  = Maximum  number  of  recycles  allowed  on  one  test. 

N.OBJ  = Number  of  objective  (review,  critique)  records. 

OBJECTIVE  NUMBER  = Number  of  the  objective  corresponding  to  that  record. 
OBJ  .NAME  = User  given  name  of  objective,  or  “EXAMX,”  REVUEX,”  “CRITQX”; 

X indicates  sequential  number. 

S.M.TYPE  = Subject  matter  type. 

TEST  = Test  indicator:  “R”  = Review;  “S”  = Exam,  but  another  exam  follows 
immediately  or  the  test  has  a critique;  “T”  = Lone  exam  or  last  in  a contiguous 
series;  “C”  = Critique. 

* 

Table  A.9  contains  further  details  on  these  variables. 

Fig.  A.4 — Training  Objectives  File:  OBJ.FILE 


Module  3:  Describe  Student  Population  and  Course 
Diversification 

In  this  phase,  the  planner  describes  how  students  arrive  for  the  course  and 
establishes  whether  the  course  is  diversified  and,  if  so,  the  forms  of  diversification 
and  how  the  students  are  categorized. 

The  flow  diagram  for  this  module  is  shown  in  Fig.  A.5,  and  Fig.  7 presents  an 
example  of  the  interaction  of  the  planner  with  the  module.  The  planner  indicates 
the  student  arrival  characteristics,  including  the  arriving  group  size  and  frequency 
parameters,  and  decides  whether  a stochastic  or  deterministic  arrival  rate  or  group 
size  will  be  simulated.  The  program  then  requests  the  planner  to  give  the  course 
diversification  policy,  indicating  the  existence  and  type  of  diversification  by  con- 
tent, method,  or  tracking. 

The  student  population  categorization  is  collected.  Here,  the  planner  can  divide 
the  student  population  in  three  categories  on  the  basis  of:  (1)  ability  alone,  (2)  "other 
characteristic,”  or  (3)  both  "other  characteristic”  and  the  student’s  ability. 
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COLLECT  CONTENT 
OR  METHOD 
DIVERSIFICATION 
POLICY 


/CONTENTS 
OR  METHOD 
\mVERS^ 


COLLECT 

TRACKING 

POLICY 


TRACKING 


COLLECT 

METHOD 

DIVERSIFICATION 

POLICY 


COLLECT 

CONTENT 

DIVERSIFICATION 

POLICY 


DETERMINE 

STUDENT 

CATEGORIES 


COLLECT 

STUDENT 

CATEGORY 

PERCENTAGES 


Fig.  A.6 — Continued  (page  2 of  2) 
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If  the  planner  chooses  to  characterize  the  student  population  on  the  basis  of 
ability  alone,  he  may  divide  the  students  into  two,  three,  or  four  categories  that  will 
be  treated  differently  on  the  basis  of  their  ability  level.  The  UI  program  requests 
the  percentage  of  students  in  each  category.  The  percentages,  starting  with  the 
slowest  ability,  are  collected;  the  UI  program  computes  the  percentage  for  the  last 
category. 

The  selection  of  "other  characteristic”  for  determining  diversification  of  the 
course  permits  the  planner  to  identify  that  other  characteristic  by  name.  Each 
student  either  has  that  characteristic  or  not;  only  two  student  categories  are  iden- 
tified on  that  basis.  To  determine  the  number  of  students  in  each  category,  the 
planner  enters  the  percentage  of  students  who  have  the  characteristic. 

The  selection  of  both  ability  and  another  characteristic  for  course  diversifica- 
tion allows  the  planner  to  categorize  the  student  population  into  four  categories, 
consisting  of  all  combinations  of  two  ability  levels  and  the  other  characteristics 
(e.g.,  fast  pilots,  slow  pilots,  fast  nonpilots,  and  slow  nonpilots).  The  planner  specifies 
the  percentage  of  the  total  student  population  (regardless  of  characteristic)  with 
the  lower  ability  level  and  (regardless  of  ability)  with  the  "other  characteristic.” 
From  these  data,  the  UI  program  estimates  the  percentage  of  the  student  popula- 
tion in  each  of  the  four  categories,  assuming  that  ability  and  the  "other  character- 
istic” are  statistically  independent.  Finally,  this  module  outputs  the  information  to 
the  file  POP.FILE  as  shown  in  Fig.  A.6.  A report  showing  the  student  population 
categorization  is  produced. 

Module  4:  Describe  Teaching  Policy 

In  this  module,  student  categories  are  allocated  to  tracks  or  groups.  Content 
skipped  by  each  category  is  specified  if  content  is  diversified  and  the  method  for 
teaching  each  subject  matter  type  in  the  course  is  defined. 

The  flow  diagram  for  this  module  is  shown  in  Fig.  A.7  and  an  example  of  its 
interaction  with  the  planner  is  shown  in  Fig.  8.  First,  the  program  requests  the 
planner  to  specify  the  length  of  the  training  day  and  the  amount  of  daily  homework 
required  in  the  course.  These  data  are  recorded  in  the  file  HMWKLN  as  shown  in 
Fig.  A.8.  If  the  planner  selects  tracking  as  a course  diversification  policy,  the 
program  requests  the  planner  to  give  number  of  tracks  and  the  student  categories 
in  each  track.  If  content  diversification  is  selected,  the  planner  indicates  the  objec- 
tives to  be  skipped  by  each  category  of  student.  The  resultant  content  diversifica- 
tion information  is  summarized  in  a report.  Finally,  the  information  to  determine 
the  teaching  method  for  each  subject  matter  type  is  collected. 

Figure  A.9  shows  that  the  teaching  policy  hierarchy  represents  the  relation- 
ships among  subject  matter  type,  group  (or  track),  and  learning  event  types.  For 
each  of  the  ten  subject  matter  types,  the  planner  may  divide  the  students  into  as 
many  as  four  groups,  which  will  be  treated  differently  even  though  they  have  the 
same  objectives.  If  tracking  has  been  selected,  these  groups  are  the  tracks  specified 
in  the  LEFIL.DESC  file;  otherwise,  they  are  any  combination  of  student  categories 
identified  during  the  description  of  the  student  population  and  course  diversifica- 
tion policy.  For  each  group  or  track  within  each  type  of  subject  matter,  the  planner 
may  choose  a different  sequence  of  learning  event  types  to  expose  the  material  to 
be  learned.  The  learning  event  types  are  selected  from  those  permissible  for  each 
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CNTNT  = Content  diversification  flag. 

METH  = Method  diversification  flag. 

TRK  = Tracking  flag. 

SARO  = Student  arrival  rule  option. 

ARR.GRP.SZ  = Student  arrival  group  size. 

ARR.G.DEV  = Student  arrival  group  size  maximum  spread. 

INTER. ARR.TIME  = Hours  between  student  group  arrivals. 

I AT  .DEV.  = Interarrival  time  deviation. 

ADAPT  .POL  = Student  population  breakdown  key. 

UPPER.ABIL  (1),  (2),  (3)  = Student  ability  level  breakdown  percentages. 

BG.PERC  = Percentage  of  students  with  other  characteristic. 

BGNAME  = Name  of  other  characteristic. 

PC.FAIL.GRP(l),  (2),  (3),  (4)  = Percentages  of  failures  from  each  student  category 
(this  information  is  added  in  the  Describe  Test  Details  module). 

*Table  A.9  contains  further  details  on  these  variables. 


Fig.  A.6 — Student  Population  and  Course 
Diversification  File:  POP.FILE 
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subject  matter  type  as  shown  in  Table  A.4.  The  permissible  teaching  format  for  each 
learning  event  type  is  shown  in  Table  A.5,  and  the  permissible  teaching  agent  for 
each  teaching  format  and  subject  matter  type  is  shown  in  Table  A.6. 

The  Teaching  Policy  routine  flow  diagram  is  shown  in  Fig.  A.  10,  and  an  example 
of  the  user  interaction  begins  on  p.  3 of  Fig.  8.  The  various  shorthand  codes  for  the 
teaching  policy  are  printed  first  at  the  planner’s  option  as  shown  on  p.  2 of  Fig.  8. 
Then,  the  program  requests  the  planner  to  provide  the  teaching  policy  for  each 
subject  matter  type  appearing  in  the  course.  The  planner’s  work  is  minimized  in 
the  following  manner: 

1.  The  planner  may  specify  that  a policy  selected  for  a previous  subject 
matter  is  to  be  also  used  for  the  present  subject  matter  type; 

2.  The  track  or  group  may  have  a policy  identical  to  one  previously  specified 
for  a track  or  group  within  the  same  subject  matter  type; 

3.  Teaching  method,  teaching  format,  and  teaching  agent  are  automatically 
assigned  when  only  a single  option  is  available; 

4.  The  planner  is  prompted  with  a list  of  allowable  replies  to  each  question. 

Once  these  data  are  collected  from  the  planner,  they  are  applied  to  the  list  of 
objectives  to  produce  the  list  of  learning  events  for  the  course.  The  first  action  in 
this  process  is  to  expand  the  list  of  objectives  into  the  appropriate  number  of  tracks 
or  groups  if  method  diversification  is  selected  and  to  provide  a set  of  "flow  codes” 
to  reflect  the  student  categories  in  each  track  or  group.  These  flow  codes  consist  of 
four-bit  binary  patterns  of  "1”  or  "0”  to  identify  which  student  categories  may  take 
a particular  learning  event  (1  if  yes,  0 if  no).  If  tracking  has  been  chosen,  flow  codes 
are  set  so  that  each  track  will  take  a separate  set  of  learning  events.  For  subject 
matter  type  with  method  diversification  and  tracking,  these  sets  will  be  different; 
for  subject  matter  type  without  method  diversification  (and  tracking)  these  sets  will 
be  the  same.  For  subject  matter  type  with  method  diversification  and  without 
tracking,  flow  codes  are  set  so  that  each  student  group  will  take  a separate  set  of 
learning  events.  For  subject  matter  type  without  method  diversification  (and  with- 
out tracking),  the  flow  codes  are  set  so  that  all  students  will  take  the  same  set  of 
learning  events. 

Each  regular  objective  (i.e.,  all  except  reviews,  critiques,  and  tests)  is  expanded 
into  a sequence  of  learning  events,  one  learning  event  for  each  learning  event  type 
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Table  A.4 

Permissible  Types  of  Learning  Events  for  Each  Subject  Matter  Type 


Subject  Presentation/  Guided  Unguided  Group  Check 

Matter  Demonstration  Practice  Practice  Discussion  Practice  Review  Test  Critique  Homework 


1 

Xa 

X 

X 

X 

X 

2 

xa 

X 

X 

X 

X 

3 

X 

xa 

X 

X 

X 

X 

X 

4 

X 

xa 

X 

X 

X 

X 

X 

5 

X 

xa 

X 

X 

X 

X 

X 

6 

X 

xa 

X 

X 

X 

X 

X 

7 

X 

xa 

X 

X 

X 

X 

8 

X 

xa 

X 

X 

X 

X 

X 

9 

X 

xa 

X 

X 

X 

X 

X 

10 

X 

xa 

X 

X 

X 

X 

X 

aEvent  types  most  typical  of  instruction  in  subject  matter  type  indicated. 


Table  A.5 


Permissible  Teaching  Formats  for  Each  Learning  Event  Type 


Teaching  Format 

Learning 

Group 

Event  Type 

Interaction 

Simple 

Recitation 

Response-paced 

Adaptive 

Presentation/ 

Demonstration 

X 

X 

X 

X 

Guided 

Practice 

X 

X 

X 

X 

Unguided 

Practice 

X 

X 

Group 

Discussion 

X 

Check  Practice 

X 

X 

Review 

X 

X 

X 

X 

X 

Test 

X 

X 

Critique 

Homework 

X 

X 

X 

X 

X 

Lai  m 


XXXXXXXXXX 
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Table  A.6 

Appropriate  Teaching  Agents  by  Teaching  Format 
and  Subject  Matter  Type 

Teaching  Format 


Subject  Group 

Matter  Type  Interaction  Simple  Recitation 


Response-paced  Adaptive 


L,  Ia,  RP 

L,  Ia,  AP 

L,  I,RP 

L,  I,  AP 

L,  I,  RP 

L,  I,  AP 

L,  I,  RPb 

L,  I,  AP 

L,  I,  RP 

L,I,  AP 

L,  I,  RPb 

L,  I,  AP 

L = Learner. 

I = Instructor. 

RP  = Response-paced  program. 

AP  = Adaptive  program. 

aExcept  homework. 
*5Presentation/demonstration  only. 


for  each  group  eligible  to  take  the  objective.  Reviews,  critiques,  and  tests  are 
converted  on  a one-for-one  basis  into  learning  events  for  each  track  or  group.  After 
the  learning  events  are  expanded,  each  learning  event  description  is  recorded  in 
the  file  ILEFIL  as  shown  in  Fig.  A.ll.  The  complete  list  of  learning  events  is  printed 
for  the  planner.  Administrative  information  is  stored  in  the  First  Learning  Event 
Description  File  LEFIL.DESC  as  shown  in  Fig.  A.  12. 

Module  5:  Describe  Test  Details 

After  the  learning  event  sequence  is  established,  the  fifth  module  collects  the 
detailed  operations  of  the  tests.  The  flow  diagram  for  this  module  is  shown  in  Fig. 
A.  13,  and  an  example  of  the  interaction  with  the  planner  is  shown  in  Fig.  13.  Here 
the  distribution  of  failures  over  the  various  student  categories  in  the  course  is 
established  along  with  the  designation  of  which  exams  cause  failures  and  recycles. 
As  shown  in  Fig.  A.ll,  these  data,  including  the  details  for  every  learning  event, 
are  stored  in  file  LEFIL.F24  with  the  extended  record  length.  The  failure  rates  for 
each  student  category  are  added  to  the  POP. FILE. 

Module  6:  Describe  Resources 

In  this  module,  the  planner  allocates  resources  to  the  learning  events  in  the 


Fig.  A.  10 — Teaching  policy  routine  flow  diagram  (page  1 of  2) 
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MAX. 
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MULT* 
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TIME. 
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n 

A3 

A3 

A6 

A6 

A6 

A6 

A6 

For  files  ILEFIL  and  LEFIL.F24: 
b = Blank. 

LENUMBER  = Learning  event  number. 

OBJ.NUM  = Objective  name  index. 

SUBJ.MATTER.TYPE  = Subject  matter  type. 

EVENT.DESCR  = Teaching  method. 

LE  TYPE  = Integer  that  points  to  teaching  method  literal. 

FLOW.CODE  = Code  that  indicates  groups  to  take  learning  event. 

TEST  IND  = Test  indicator:  ‘R”  = Review;  “S”  = Exam,  but  another  exam  follows  immediately  or 
the  test  has  a critique;  “T”  = Lone  exam  or  last  in  a contiguous  series  or  a critique. 

TEA  FMT  = Number  that  refers  to  teaching  format. 

TEA  AGT  = Number  that  refers  to  teaching  agent. 

GRP/TRK  NO.  = Number  of  group  or  track  that  is  taking  learning  event  (1  if  no  diversification). 
The  following  are  added  for  file  LEFIL.F24: 

P. FAILS  = Failure  key. 

PC. RECYCLE  = Percentage  of  students  who  will  recycle  back  from  test. 

LEREC  = Learning  event  for  start  of  recycle. 

MAX. STUDENTS. ALLWD  = Maximum  number  of  students  allowed  in  learning  event. 
MIN.NO.STUDENTS.REQD  = Minimum  number  of  students  allowed  in  learning  event. 

AVG.TIME. ALLWD  = Completion  time  for  learning  event. 

MAX.TIME.MULT  = Maximum  time  multiple  of  AVG.TIME.ALLWD. 

MIN.TIME.MULT  = Minimum  time  multiple  of  AVG.TIME.ALLWD. 


Table  A. 9 contains  further  details  on  these  variables. 


! 


Fig.  A.  11— Learning  Event  Files:  ILEFIL  and  LEFIL.F24 


22 


KEY 

N.LE 

DIVS 

TRKS 

EXAMS 

FAILS 

RECYC 

ADAPT 

AP/RP 

“)b” 

DESCRIPTOR* 

13  II  II  II  II  II  II  II 


INST 

LEAR 

EVAL 

MONIT 

OTHER 

CHARACTERISTIC 

NAME 

NO.  OF  RES. 

11 

11 

11 

11 

A8 

12 

RESOURCE  NAMES 

(31-8  Character  names  packed  62  characters /record  in  4 records)  J 
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31  II 


Fig.  A.12 — Learning  Event  Description  Files: 
LEFIL.DESC  and  LEFIL.D2  (page  1 of  2) 
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For  files  LEFIL.DESC  and  LEFIL.D2: 


$ = Blank 

N.LE.DESCRIPTOR  = Total  number  of  learning  events. 

DIVS  = Diversification  indicator. 

TRKS  = Number  of  tracks. 

EXAMS  = Exam  flag. 

FAILS  = Failure  flag. 

RECYC  = Recycle  flag. 

ADAPT  = Adaptive  policy. 

AP/RP  = Adaptive  program  or  response-paced  program  as  agent  flag. 

INST  = Instructor  as  agent  flag. 

LEAR  = Learner  as  agent  flag. 

EVAL  = Evaluator  flag. 

MONIT  = Monitor  flag. 

OTHER  CHARACTERISTIC  NAME  = Other  student  characteristic  name. 

NO.  OF  RES.  = Number  of  resources. 

RESOURCE  NAMES  = User  assigned  resource  names. 

RESOURCE  ALLOCATION  BIT  MAP  = Resource  allocation  for  each  of  the  250  learning  events. 
POLICY  EXISTENCE  LIST  contains  553  elements  as  follows: 


Elements 


Contents 


1-10 

11-19 

20-23 

24-113 

114-473 

474-513 

514-553 


S.M.  EXIST  = Indicates  if  that  subject  matter  exists 

L.E.T.  EXIST  = Indicates  if  that  learning  event  type  exists. 

TRACK  = Indicates  if  that  track  exists. 

S.M.  L.E.  TYPE  = Indicates  if  that  subject  matter,  learning  event  type 
combination  exists. 

S.M.  TRK  L.E.  TYPE  = Indicates  if  that  subject  matter,  track  and  learning 
event  type  combination  exists. 

S.M.  TRK/GRP  = Indicates  if  that  subject  matter,  track  or  group  combination 
exists. 

TRK/GRP  CAT  IND  = Indicates  if  that  track/group  and  subject  matter 
combination  exists. 


The  following  is  added  for  file  LEFIL.D2: 

MEDIA  EXISTENCE  = Indicator  for  resource  used  as  MEDIA. 


a|e 

Table  A.9  contains  further  details  on  this  variable. 


Fig.  A. 12 — Continued  (page  2 of  2) 
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course.  The  flow  diagram  is  shown  in  Fig.  A.  14,  and  an  example  of  an  interaction 
with  the  planner  is  shown  in  Fig.  15. 

First,  the  planner  assigns  special  resources  to  learning  events  with  subject 
matter  types  7 through  10.  The  UI  program  prompts  the  planner  for  the  assign- 
ments. 

Next,  the  planner  allocates  the  non-special  resources.  They  are  generated  in  the 
following  resource  category  order:  instructors,  evaluators,  monitors,  facilities,  in- 
structor support  media,  learner  support  media,  program  support  media,  and 
recording  hardware.  The  allocations  are  made  learning  event  by  learning  event  or 
by  combinations  of  learning  events.  These  combinations  constitute  the  resource 
assignment  policies.  The  combinations  and  their  codes  are  shown  in  Table  A.7.  The 
UI  program  prompts  the  planner  with  acceptable  resource  assignment  policies  for 
each  resource  category;  the  valid  assignment  policies  for  the  various  categories  are 
shown  in  Table  A.8.  In  addition,  for  some  resource  categories,  the  program  further 
validates  the  assignment  (e.g.,  the  program  assigns  instructor  types  only  to  those 
learning  events  for  which  the  teaching  agent  is  an  instructor).  See  notes  on  Table 
A.8  for  these  validations. 

The  Total  Resource  Assignment  Report  is  produced  following  the  assignment. 
The  planner  is  then  given  an  opportunity  to  modify  the  resource  assignment.  The 
data  are  stored  in  file  LEFIL.D2  in  the  format  shown  in  Fig.  A.  12. 

Module  7:  Describe  Resource  Constraints 

After  all  of  the  resources  have  been  assigned,  the  seventh  module,  whose  flow 
diagram  is  shown  in  Fig.  A.  15,  helps  the  planner  describe  the  resource  constraints. 
Also  in  this  phase,  the  planner  determines  the  time  and  section  size  limitations  of 
each  learning  event.  An  example  of  the  planner  interaction  is  shown  in  Figs.  19 
through  26. 

First,  the  UI  program  requests  the  capacity,  quantity  available,  and  sharing 
policy  for  each  resource.  Provision  is  included  to  accept: 

1.  Unknown  capacities  (to  be  estimated  by  RUM), 

2.  Capacities  that  vary  from  one  learning  event  to  another, 

3.  Unknown  quantities  (to  be  estimated  by  RUM), 

4.  Wholly  dedicated  resources, 

5.  Wholly  shared  resources, 

6.  A list  of  learning  events  that  can  share  a resource. 

The  resource  constraints  (capacities,  quantities  available,  and  sharing  policy)  are 
recorded  in  the  RUMRES  file  in  the  format  shown  in  Fig.  A.  16.  A summary  of  the 
resource  constraints  is  produced  at  the  planner’s  option. 

Next,  the  program  requests  the  quantities  "maximum  section  size,”  "minimum 
section  size,”  "average  student  time,”  "maximum  allowed  time  factor,”  and  "mini- 
mum allowed  time  factor”  for  all  learning  events.  The  planner  may  use  the  resource 
assignment  policy  codes  to  combine  learning  events,  just  as  was  possible  for  specifi- 
cation of  the  resources  in  Module  6.  A report  giving  the  "Complete  Time  and 
Section  Size  Assignment”  is  produced.  The  planner  may  correct  the  section  size  and 
time  assignments  at  this  point. 

The  planner  then  has  the  option  of  requesting  the  next  two  reports:  "Summary 
of  Course  Design”  and  "Summary  of  Resource  Characteristics.”  The  "Summary  of 
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Fig.  A.  14 — Describe  resources  flow  diagram 
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Table  A.7 

Learning  Event  Combinations  for 
Resource  Assignment 


Code 

Meaning 

N 

None 

W 

Whole  Course 

B 

Block  of  sequential  learning  events 

SM 

Subject  matter  type 

T 

Student  track 

LET 

Learning  event  type 

SMLE 

Subject  matter  type  and  learning  event  type 

SMGT 

Subject  matter  type  and  student  group/track 

SMLS 

Subject  matter  type,  learning  event  type, 
and  student  group/track 

LE 

Individual  learning  event 

Table  A.8 

Valid  Resource  Assignment  Policies 


Resource  Assignment  Policy  Code 

Resource 

Category 

W 

B 

SM 

LET 

T 

SMLE 

SMGT 

SMLS 

LE 

N 

Special  Resources 

X 

Instructors® 

X 

X 

X 

X 

X 

X 

X 

X 

Monitors*’ 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Evaluators0 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Facilities 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Instructor  Support 
Media® 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Learner  Support 
Mediad 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Program  Mediae 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Recording  Hardware 

X 

X 

X 

X 

instructors  are  assigned  to  learning  events  for  which  the  teaching  agent  is  an  instructor. 

^Monitors  are  assigned  to  learning  events  for  which  the  subject  matter  type  is  7 or  greater,  or  the 
subject  matter  type  is  6 or  less  and  the  teaching  agent  is  not  an  instructor. 

cEvaluators  are  assigned  to  learning  events  for  which  the  learning  event  type  is  test,  critique,  or 
check  practice. 

d Assigned  to  learning  events  for  which  the  teaching  agent  is  a learner. 

eAssigned  to  learning  events  for  which  the  teaching  agent  is  an  adaptive  program  or  a response- 
paced  program. 


i^l 
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Fig.  A.  15 — Describe  resource  constraints  flow  diagram  (page  1 of  3) 
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Fig.  A.  15 — Continued  (page  2 of  3) 
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Repeated  N.RSOURCE.TYPE  times: 

CAP  .CODE 

QTY.CODE 

SHR.CODE 

17 

17 

11 

KEY 

“K>” 

N VAR  .CAPS 

13 

Repeated  N VAR  .CAPS  times: 


NVC  (Packed  11  capacities  per  record  for 
number  of  learning  events) 


11  17 


KEY 

NVAR.SHR 

13 

Repeated  NVAR.SHR  times: 


KEY 

NVS  (Packed  31  items  per  record  for 

“b  ” 

number  of  learning  events) 

31  11 

Repeated  31  times: 

NAME 

A8 

Repeated  N.RSOURCE.TYPE  times: 

RESRC.REQMT.TABL  (Packed  50  items  per  record 
for  250  learning  events) 

50  II 


Fig.  A.  16 — Resource  Constraints  File:  RUMRES  (page  1 of  2) 


32 


|6  = Blank. 

N.RSOURCE.TYPE  = Number  of  resources. 

CAP.CODE  = Capacity  code  for  the  resource. 

QTY.CODE  = Quantity  code  of  the  resource. 

SHR.CODE  = Sharing  code  for  the  resource. 

NVAR.CAPS  = Number  of  resources  with  varying  capacity. 

NVC  = Capacity  of  each  resource  with  a varying  capacity  for  the  learning  events. 
NVAR.SHR  = Number  of  variable  sharing  resources. 

NVS  = Share  code  of  each  resource  with  varying  shareability  for  the  learning  events. 
NAME  = User  assigned  names  for  31  resources. 

RESRC.REQMT.TABL  = Resource  use  indicator  for  250  learning  events. 


Table  A. 9 contains  further  details  on  these  variables. 

Fig.  A.  16 — Continued  (page  2 of  2) 
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Course  Design”  is  an  extensive  report  and  displays  the  learning  events,  the  teach- 
ing method  assigned  to  each,  the  categories  of  students  taking  each,  the  section  size 
and  time  descriptions,  and  the  resources  assigned. 

Two  other  reports  are  produced  (not  optional)  in  this  phase:  "Summary  of 
Course  Minutes  and  Equivalent  Days”  and  "Summary  of  Media  Usage.”  The  first 
report  summarizes  the  time  spent  in  classroom  instruction  and  in  homework  for 
each  student  category.  These  totals  are  printed  both  as  minutes  and  as  equivalent 
days  using  the  length  of  the  training  day  and  the  time  required  for  daily  homework, 
i The  "Summary  of  Media  Usage”  report  displays  the  use  of  each  media  type  in  the 

course.  The  list  is  sorted  by  media  type,  objective,  teaching  agent,  teaching  format, 
learning  event  type,  group  or  track,  and  subject  matter  type;  it  displays  all  learning 
events  to  which  the  planner  has  assigned  media. 

Module  8:  Describe  Resource  Utilization  Model  Parameters 

This  module  collects  the  remaining  RUM  parameters  that  control  the  length  of 
the  RUM  simulation  and  the  frequency  with  which  the  intermediate  reports  are 
generated.  It  also  allows  the  planner  to  modify  the  student  arrival  characteristics. 
The  flow  diagram  of  the  eighth  module  is  shown  in  Fig.  A.  17;  an  example  of  the 
planner  interaction  is  shown  in  Fig.  27. 

After  requesting  the  time  interval  between  RUM  reports,  the  UI  program  asks 
the  planner  to  decide  whether  the  number  of  graduates  or  the  elapsed  simulated 
time  since  the  beginning  of  the  course  is  to  be  used  to  terminate  the  simulation.  In 
either  case,  the  program  then  requests  the  value  to  be  used  to  test  for  the  end  of 
the  simulation.  The  run  control  data  are  recorded  in  the  SCHD.TIM  file  in  the 
format  shown  in  Fig.  A.18.  The  student  population  arrival  rates  and  arrival  group 
sizes  may  then  be  respecified  by  the  planner  as  was  done  earlier  in  the  Describe 
Student  Population  and  Course  Diversification  module.  The  revised  data  are 
recorded  in  the  file  POP.FILE  as  shown  in  Fig.  A.6,  replacing  those  recorded  earlier. 

Module  9:  Convert  Course  Design  Data  to  RUM  Format 

The  last  module  merges  and  transforms  the  UI  data  stored  in  the  various 
intermediate  files  into  a single  file,  RUMINPU,  which  represents  the  entire  course 
design  for  input  to  the  RUM.  Some  of  the  values  stored  as  percentages  in  the 
intermediate  files  are  converted  to  fractions.  The  order  and  format  are  shown  in 
Table  A.9.  This  is  a straightforward  mapping  of  available  data  from  the  existing 
UI  files,  so  no  flow  diagram  for  this  module  is  included  here. 
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Fig.  A.  17 — Describe  resource  utilization  model 
parameters  flow  diagram 
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KEY 

REPORT 

SIM. 

ENDVAR 

“b” 

INTERVAL 

END. 

OPT 

A4 

A1 

A4 

K>  = Blank 

REPORT.INTERVAL  = Number  of  hours  between  RUM  reports. 
SIM.END.OPT  = Simulation  end  option. 

END  VAR  = End  variable. 


Table  A. 9 contains  further  details  on  these  variables. 


Fig.  A.  18 — RUM  Control  File:  SCHD.TIM 
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Table  A.9 

UI/RUM  Interface  File:  RUMINPU 


The  UI  program  provides  the  RUM  with  the  data  described  below  in  a “free-form,”  blank  delimited,  80  character 
record  file.  The  data  items  are  described  in  the  order  in  which  they  appear  in  the  file  RUMINPU,  with  the 
corresponding  RUM  variable  names. 


Name 

Description 

Format 

Min 

Max 

SARO® 

Student  arrival  rule  option : 

1:  Fixed  group  size,  fixed  inter- 
arrival time. 

2:  Random  group  size,  random 
inter-arrival  time. 

3:  Random  group  size,  fixed  inter- 
arrival  time. 

4:  Fixed  group  size,  random  inter- 
arrival time. 

Integer 

1 

4 

ARR.GRP.SZ 

Group  size  or  mean  group  size  of 
arriving  students. 

Integer 

1 

999 

INTER. ARR.TIME 

Inter-arrival  time  or  mean  inter- 
arrival  time  of  students. 

Integer 

1 

999 

ARR.G.DEV 

“Three  sigma”  deviation  from  mean 
ARR.GRP.SZ  above  (provided  if 
SARO  is  3). 

Integer 

1 

999 

IAT.DEV 

“Three  sigma”  deviation  from  mean 
INTER. ARR.TIME  above  (provided 
if  SARO  is  4). 

Integer 

1 

999 

REPORT. INTERVAL 

Hours  between  RUM  reports. 

Integer 

1 

9999 

SIM.END.OPT 

Simulation  end  option; 

0:  run  for  ENDVAR  simulated 
hours. 

1:  run  until  ENDVAR  students 
graduate. 

Integer 

0 

1 

ENDVAR 

Number  of  simulated  hours  or 
students  graduated  for  RUM  run. 

Integer 

1 

9999 

ADAPT.POL*5 

Course  adaptability  policy. 

0:  no  adaptability 

1 : 2 groups  based  on  some 
characteristic. 

2:  2 groups  based  on  ability 

3:  3 groups  based  on  ability 

4:  4 groups  based  on  ability 

5:  4 groups  based  on  ability  and 
some  other  characteristic. 

Integer 

0 

5 

BGNAME 

Name  of  the  characteristic  (provided 
if  ADAPT.POL  is  1 or  5). 

Alpha 
(8  char.) 

— 

— 

BG.PERC 

Fraction  of  students  with  the  other 
characteristic  (provided  if 
ADAPT.POL  is  1 or  5). 

Real 

.01 

.99 

UPPR.ABlL(l) 

Fraction  of  students  in  slowest 
ability  group  (provided  if 
ADAPT.POL  is  from  2 to  5 
inclusive). 

Real 

.01 

.99 

UPPR.ABIL(2) 

Fraction  of  students  in  two  slowest 
ability  groups  (provided  if 
ADAPT.POL  is  3 or  4). 

Real 

UPPR. 

ABIL(l) 

.99 
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Table  A. 9— continued 


UPPR.ABIL(3) 


FAILRATE 


Description 

Fraction  of  students  in  three  slowest 
ability  groups  (provided  if  ADAPT. 
POL  is  4). 

Fraction  of  students  who  fail  the 


UPPR. 
AB1L  (2) 


PC.FAIL.GRP 


N.OBJc 

OBJ.NAME 


N.LE. DESCRIPTOR 

LENUMBERd 

OBJ.NUM  Related  objective  index. 

SUBJ.MATTER.TYPE  Subject  matter  type. 

EVENT .DESCR  Teaching  method. 

AVG.TIME.ALLWD  Average  minutes  for  learning  event. 

FLOW  .CODE  A 4 bit  code  indicating  which  stu- 

dents must  attend  the  learning  event. 
Starting  with  the  least  significant 
bit,  the  bits  represent  the  slowest 
ability  group  and,  within  each 
ability,  the  group  with  the  character- 
istic first. 

MAX.STUDENTS.ALLWD  Maximum  students  for  learning 
event. 


Fraction  of  students  in  each  group 
who  fail.  Up  to  4 values  provided 
(depending  on  ADAPT. POL)  in 
order  of  slowest  ability  group  first 
and,  within  each  ability,  the  group 
with  the  characteristic  first. 

Number  of  objectives. 

Objective  names  (in  order). 


Number  of  learning  events, 
Learning  event  number. 


Integer 

Alpha 
Array 
(8  char.) 

Integer 

Integer 


Integer 

Integer 

Alpha 
(2  char.) 

Integer 

Integer 


MIN.NO.STUDENTS. 

REQD 

MAX.TIME.MULT 
MIN. TIME. MULT 
P.FAILS 


PC. RECYCLE 


MAX. NO. RECYCLES 


Minimum  students  for  learning 
event. 

Maximum  student  rate  (compared 
with  average). 

Minimum  student  rate  (compared 
with  average). 

Failure  key  (provided  if 
EVENT.DESCR  is  “T.”): 

0:  no  failures. 

1:  some  failures. 

Fraction  of  passing  students  re- 
cycling to  earlier  learning  event 
(provided  if  EVENT.DESCR 
is  “T.”). 

Learning  event  for  start  of  re- 
cycle (provided  if  PC. RECYCLE 
greater  than  0). 

Maximum  recycles  allowed  for  a 
single  student  (provided  if 
PC  .RECYCLE  greater  than  0). 


Integer 


Integer 


N.LE.  DES- 
CRIPTOR 


MIN. NO.  999 

STUDENTS. 

REQD 


less  than 
LENUMBER 
of  the  test 
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Table  A.9— continued 


Name 

Description 

Format 

Min 

Max 

N.RSOURCE.TYPEe 

Number  of  resources. 

Integer 

0 

31 

TYPE.ID.NOf 

Resource  index. 

Integer 

1 

N. 

RSOURCE.TYPE 

NAME 

Resource  name. 

Alpha 
(8  char.) 

— 

— 

CAP.CODE 

Resource  capacity  code: 

- 1 : undefined  capacity. 

0:  varying  capacity  (see  NVC 
below). 

1 999:  number  of  students  that  one 
unit  of  the  resource  can 
accommodate. 

Integer 

-1 

999 

QTY.CODE 

Resource  quantity  code: 

0:  unlimited  quantity. 

1-  999:  number  of  units  of  resource 
available. 

Integer 

0 

999 

SHR.CODE 

Resource  sharing  code 

1 : dedicated  to  one  learning 
event  at  a time. 

2:  may  be  shared  by  any  number 
of  learning  events. 

3:  may  be  shared  only  by  special 
learning  events  (see  NVS  below). 

Integer 

1 

3 

NVAR.CAPS8 

Number  of  resources  with  varying 
capacity. 

Integer 

1 

31 

NVC 

Capacities  of  variable  capacity 
resources,  provided  in  order  of  re- 
sources for  each  learning  event. 

Integer 

Array 

1 

999 

NVAR.SHRh 

Number  of  variable  sharing  re- 
sources. 

Integer 

1 

31 

NVS 

Sharing  codes  (see  SHR.CODE)  for 
each  resource  in  each  learning  event, 
provided  in  order  of  resources  for 
each  learning  event. 

Integer 

Array 

1 

2 

RESRC.REQMT.TABL' 

Resource  allocation  indicator,  pro- 
vided in  order  of  resources  for  each 
learning  event: 

0:  not  needed. 

1 : needed . 

Integer 

Array 

0 

1 

^he  data  SARO  through  ENDVAR  describe  the  student  arrival  characteristics  and  the  control  information 
for  the  RUM  run  that  governs  the  frequency  of  reports  and  the  duration  of  the  simulation. 

^The  data  ADAPT.POL  through  PC.FAIL.GRP  describe  the  adapability  of  the  course  design  to  different 
students  and  the  failure  policy  for  the  course. 

cThe  data  N.OBJ  through  N.LE.DESCRIPTOR  describe  the  objectives  in  the  course  and  indicate  the  number 
of  learning  events  in  the  course. 

<*The  data  LENUMBER  through  MAX.NO. RECYCLES  describe  each  learning  event  in  detail  and  are  recorded 
in  order,  one  set  for  each  learning  event. 

eN.RSOURCE.TYPE  indicates  the  number  of  resources  required  for  the  course. 

^The  data  TYPE.1D.NO  through  SHR.CODE  describe  each  resource  in  turn  and  are  recorded  in  order,  one  set 
for  each  resource. 

*The  data  NVAR.CAPS  through  NVC  describe  the  capacity  of  any  resource  whose  capacity  was  specified  as 
variable  (CAP.CODE  is  zero).  They  are  provided  only  for  those  resources  if  at  least  one  variable  capacity 
resource  occurs. 

hThe  data  NVAR.SHR  through  NVS  indicate  the  policy  for  variable  sharing  resources  (SHR.CODE  is  3)  and 
are  provided  only  for  those  resources  if  at  least  one  resource  with  a variable  sharing  policy  occurs. 

'H  MHC  iKjMT.TABL  represents  the  allocation  of  resource*  to  learning  events. 


' 


